Hi All, I know this has been covered to death, but unfortunately the 3.75 million Google/Bing responses don't appear to help me. We have, as of November 2009, taken the plunge with "Windows 7 Professional x64" across site, and up until a few weeks ago, everything has been working well. Unfortunately, we have developed a quite odd wireless issue with regards to on/off switch use and Sleep/Hibernate. I am seeing this issue on a couple of hundred computers, using a few different devices (and therefore drivers), and it seems specific to one domain. Here's what we know. The three affected systems in our environment are; Toshiba Portege M750ES Tablet - Intel WiFi Link 5100 AGN (VEN_8086&DEV_4232) Toshiba Portege M405E Tablet - Intel Pro Wireless 3495ABG (VEN_8086&DEV_4222) Toshiba Satellite T110 Notebook- Realtek RTL8191SE Wireless LAN PCI-E (VEN_10EC&DEV_8172) Unfortunately I can't list any other devices, as these make up 99% of our wireless fleet, and the other 1% are using "Windows XP" which are NOT affected by the issue. This issue ONLY affects the computers running "Windows 7 Professional x64" in our environment. Installing any of the above systems with "Windows XP Professional SP3" cannot reproduce the issue, even if that exact system was affected with the issue under "Windows 7". We've tried vendor-supplied drivers, checked for newer drivers from Intel and Realtek (there were none), and the issue has only JUST shown up - so surely that can't be the issue. Our environment is a "Server 2008 R2"-based (2008 Functional) Domain for user authentication. Our network is an 802.1X PEAP/MSCHAPv2 network with "Fast Reconnect" enabled. These settings are deployed to the system via "Group Policy" and can be seen on the affected systems. These can also be seen on the "Windows XP" systems, and it works perfectly. The hardware for the wireless network is a pair of Nortel 2300-series management controllers and their APs. Authentication is handled by a "Server 2003" IAS/RADIUS server. When these "Windos 7" computers are first turned on or logged on, everything is fine. If the user's enter a "Sleep" or "Hibernate" state and resumes, the wireless network does not work. We've been able to reproduce, what appears to be the same behaviour, simply by turning the wireless switch off and then back on several seconds later. The computer responds with "Not connected - Conenctions are available", with our defined SSID present, however it will fail when you attempt to connect. Attempting to manually connect will fail. Disabling and Enabling the adapter will fail. Using the soft-key functions to disable and enable the adapter will fail. Disabling the "Power Management" feature before another rounds of tests result in the same failure. Troubleshooter will fail. Logging off and then back on will succeeds (as will a reboot, obviously). While this is all happening, the IAS is showing both the machine auth and user auth processes and is succeeding. So even though the computer asks for authentication and is granted access, the network will not connect. When the network is not connected, the adapter status will frequently say "Attempting to authenticate" for several seconds before changing back to "not connected". When this occurs, another "success" entry shows up in the IAS log. I have tried blocking all policy on the computers and defining the SSID/802.1X settings myself (which works initially), but the same "Sleep" issue exists. I have also tracked down future SP1 updates KB976373 and KB980295, but neither help. What really hurst my head, is that if we add the computer to our second (parent) domain in the forest, then it will succeed - even with the exact same user account. And it doesn't matter if the user account if from the first or second domains. So let me break that down for you; Test computer A (blocking all policy inheritance) on domain TWO with a user from domain ONE logged on = Works. Computer A (above) entering "Sleep" and coming out will fail to connect to the wireless network... until rebooted or user logs out and back on = Fails. Test computer A (still blocking all policy inheritance), now joined to domain ONE with the same user from domain ONE logged on = Works. Repeat "Sleep" process on domain "ONE" = Works. The IAS logs look the same for both domain tests, and is showing successful authentication. Now, we do operate different VLANs for these domains... but surely that shouldn't be causing the issue, as a log off/on will work correctly. I am really confused with this issue. It's worse considering the problem has only popped up now, several months after the deployment. Anything see something in there that may help me? Thanks

Just so its "out there"... here are some of the troubleshooting results I get. NOTE: I've condensed a LOT of text here by removing standard messages and success values etc. Below is the "stuff" I think will be useful. I can post the entire troubleshooter log if required. Result of diagnosis: Problem found Issue referred to: L2Sec Helper Class Helper Class: Layer2 Security Initialize Status: Success Result of diagnosis: Problem found Root cause: Windows cannot connect to "<NetworkName>" Wireless authentication failed because of a timeout. Detailed root cause: Layer 2 security key exchange following 802.1X did not generate unicast keys before timeout Information for connection being diagnosed Connection mode: Infra Security enabled: Yes Pre-Association and association status: Success Security and Authentication: Configured security type: Open Configured Encryption type: WEP Security connect status: Fail 0x00048005 Number of security packets received: 6 Number of security packets sent: 6 802.1X protocol: Yes Authentication Identity: Machine or user IAS Server engaged: Yes EAP Method supported by IAS Server: Unknown EAP type: 25 EAP Error: None Number of 802.1X restarts: 0 Number of 802.1X failures: 0 802.1X status: Success Key exchange initiated: Yes Unicast keys received: No Multicast keys received: No To test the issue, I have; Created a new test user with all the appropriate memberships and settings to test our environment. Moved the new test user into an OU that is set to block policy inheritance and does not contain any GPOs. Removed the "Logon Script" setting - just in case. Set the user "Profile path" to a network location (using subfolder of "%HOMESHARE%" - with "Full Control" permissions). Copied a known-good (unaffected) user profile to that location and checked security settings. Will use this profile to test the system. Created a new computer account and located this in an OU that blocks all policy inheritance and does not contain any GPOs. Linked in our test "WLAN Policy" that contains ALL the working settings from our first domain (where the issue is not present). Deployed the computer using a "Factory Recover" disc and completed the OOBE manually. Added the new computer to the domain such that it takes the new computer account created above. Due to it being a "Factory" image, it did NOT contain an active AntiVirus program - and we left it that way for testing. Also due to it being a "Factory" image, it did not contain our WSUS server settings... and we turned off "Automatic Update" for this test. Added the test user as an administrator on the computer. Logged on to the new system as the test user - the copied profile took, so we made it a "Local profile". Rebooted to start from a new session. As soon as we logged on as the test user, we noticed that the wireless HAD connected. We then put the computer into "Sleep" using the start menu option. After several seconds, we resumed the session and logged back on. Wireless status was "Not connected - Connestions are available". Our wireless network was listed, has the correct settings (via "Properties" menu option) and is showing full strength (less than 10 metres from the AP). Clicked "Connect" and after a few seconds received the message "Unable to connect to <NetworkName>". It will also try automatically (every now and then) and will also fail. NOTE: Each time it fails, our IAS reports a success. The only way to get the wireless to work is to restart teh user session (log off and back on, or restart the computer). We're not happy! We have 265 users affected by this that are "High Priority" and some couple of hundred listed as "Medium Priority". Anyone got a suggestion for me?

Can you believe that all this pain was caused by the setting "Fast Reconnect" within the 802.1X/PEAP wireless configuration settings (policy)? This "default on" option was causing all my issues. Even though this WAS working before, and we can't see any changes to our environment that could have caused the issue, as soon as we tested a new GPO "WLAN Policy" with this setting removed, our wireless clients began working again. Quite odd as a number of IAS/802.1X recommended procedure documents claim that enabling this option is a good idea (and probably why it's on by default). To borrow a description or two from various sites: Enabling fast reconnect can eliminate a great deal of packet loss for roaming clients, and is a must for mission critical mobile applications. When enabled, the session keys for the network are cached so that a client can roam from AP to AP in a more seamless manner. Unfortunately, I think that something has changed (maybe a key update interval) and is causing the cached keys to "expire". Turning this option off will likely reduce the efficiency of our connected/roaming clients, but at least it will enable the wireless network to operate without the need for a reboot.

Interesting comments. I am experiencing a very similar problem with WPA2-Enterprise Computer Certificate based EAP-TLS on Windows 7 Enterprise x64. In my network case we are using Cisco WAPs, Wireless controller, and Cisco ACS infrastructure. This looks to be a Windows 7 problem and not infrastructure. Similar to your experiences, if the session is disconnected due to lower power state, cycling the wireless hardware switch or user disconnect in the system tray the system will not reconnect without additional "help". Here, network captures show that the Wireless Adapter is not sending the EAPOL Key negotiation to initiate reconnection. On Windows XP the EAPOL Key traffic is sent. (We are using wired IEEE 802.1x EAP-TLS with no reported issues yet of this type on the copper). The two ways to reinitiate the Wireless connection are to reboot the system or connect an ethernet cable to the RJ-45 port. Connecting ethernet cables causes EAPOL Keys to be sent over the wireless adapter and the wireless reconnection succeeds. This is either really bad design or a bug. Currently am awaiting Microsoft response on this.

Hi Chris, Did you ever get a resolution to this? We're experiencing a very similar problem with Cisco WAPs also, but I haven't had a chance to sniff the traffic and verify the EAPOL Key negotiation. I'm assuming I'll see your issue though. Any info or resolution would be greatly appreciated. -Tim